It would be nice to say that Windows NT takes care of every problem, and that you'll never experience any kind of software error ever again, but that wouldn't be reality. Windows NT does provide a level of safety you've probably never seen before. It's a lot better than either Windows 95 or Windows 3.x from a security standpoint. If an application is ill-behaved, Windows NT kills it immediately. (In four months of extensive application testing, I never encountered a GPF or system crash under Windows NTeither the application would run or it wouldn't.) Of course, that protection is a two-edged sword. Sure, you'll experience fewer software problems under Windows NT, but part of the reason is that Windows NT is so incredibly inflexible that a lot of those problem applications won't run at all.
Let's take a quick look again at Windows NT versus Windows 95. When you look at Windows 95, you're seeing a middle ground of reliabilitynot the best there is. Microsoft had to make some concessions to allow all the products you used under Windows 3.x to run under Windows 95 as well. In addition, there was a problem with getting enough security in a package that also runs in 8MB of RAM to take care of every kind of software-integrity problem. Windows NT comes out and says that it needs gargantuan amounts of RAM right on the package. A lot of that extra RAM is used to keep your machine from crashing when running marginal software. Not listed on the package are all the applications it won't run at all because of the wealth of security features it provides. After Dark, a screen saver that runs fine under both Windows 3.x and Windows 95, for example, won't run at all under Windows NT.
So how do these limitations affect you? First, you'll still have problems with GPFs when running a problem application under Windows 95, but at least it will run. Windows NT provides a very strict environment for sensing programs that make illegal calls and recovers from them by terminating the offending application. This won't quite work with some applications that depend on those illegal calls to run. As I've said throughout most of the book, you'll always have a trade-off: added flexibility with Windows 95 or added reliability with Windows NT.
Another problem occurs with DOS support. In the Windows 95 environment, when your application switches to real mode to run, the operating system is vulnerable to attack. There's no real mode when using Windows NTit builds a true virtual machine for your application to run in and never loses even a modicum of control. Windows NT handles DOS application problems by implementing a strict set of rules. A DOS application that breaks even the smallest of those rules gets terminated, just like its Windows counterpart. As with the Windows applications, Windows 95 relaxes these rules so that more applications can run. The result is that an errant application can crash the system. What does this mean in real terms? Most of you who want to run games on your computer will be extremely disappointed with the kind off support Windows NT provides. On the other hand, I can get the vast majority of the games I've tried to run just fine under Windows 95. The trade-off is sharp, though, even for a business user. A lot of old graphics programs just didn't follow the rules. An older copy of Harvard Graphics that works fine under Windows 95, for example, won't even get past the splash screen under Windows NT.
Tip: The best advice I can give you is to test before you buy. If that old application is important and it won't run under Windows NT in the store, no amount of fiddling will make it run on your computer at work either. Take a look at Windows 95 before you make a Windows NT decision if you have marginal applications to run.
Fortunately, you'll still notice a superior level of support from Windows 95. It recovers from a great many more problems than Windows 3.x does. In addition, as you switch from 16-bit applications to their 32-bit counterparts, you'll gain the benefit of that protected environment. The more 32-bit applications you use, the less your chances are of the system crashing.
I've been testing Windows NT pretty thoroughly over the course of writing this book. I've changed the registry and tested what will and won't work. Setup also got a good workout as I added and removed applications. I even changed the network setup quite few times to test different configurations. If Windows NT ever had a good reason to crash, it was while I kept changing its configuration. During this time, I didn't experience a single crash (contrasted with about one per day with Windows 95 when I did a similar level of testing on it). I did manage to lose a single user account, but the registry changes I was trying were pretty severe. That's great, considering what I put Windows NT through.
The bottom line? You don't get anything for free. That applies to operating systems as well. Windows NT is going to be the best you can do when it comes to well-behaved, mission-critical applications. I don't think I would settle for anything less when it comes to a data entry program or inventory control system. For those people who don't want an operating system that places their applications in a straitjacket and forces them to buy new ones, however, Windows NT is definitely not the answer. These folks will want something that'll run their old stuff well and their new stuff even better. That's what Windows 95 provides, but it comes at the cost of system stability.
The next couple of sections cover from a software perspective some of the problems you'll experience. I'll also tell you about some of the fixes Microsoft provides to alleviate them. Will those fixes always work? Probably not. Fortunately, these fixes always work. I can't say the same thing for Windows 95. During one incident, I had to actually reinstall Windows 95 and all the applications I use because the registry got trashed beyond recognition. An application decided to overwrite some files that would have been fine under Windows 3.x but not under Windows 95. Suffice it to say that you'll experience fewer problems under Windows NT and that the cures Microsoft provide work most of the time, but thinking that they'll cure every problem just isn't realistic.
Configuration problems normally manifest themselves in several ways. The most devastating problems are during system startup. Have you ever seen the infamous blue screen (not the one that appears during startup, but the one that appears when something really strange happens to the machine)? If you reconfigure your machine as often as I do, you're definitely going to see it. Fortunately, Windows NT is a lot less prone to this problem than Windows 95. During similar periods of the same types of configuration changes (those required to write a book), Windows NT only displayed the blue screen of death one time. Windows 95 displayed it four timesstill an admirable record, considering what I put it through.
The other types of configuration problems are a lot more devious. They usually rob your system of its flexibility or make some of its components unusable. You'll find yourself running in circles trying to identify the culprit, only to find that it wasn't any of the things you suspected at all. One of the problems I found in this category was my sound board. I couldn't figure out what was wrong. The Midi Balance setting kept getting out of whack. I looked at the driverno luck. The same held true with the hardware itself. I thought there might be a problem in the way the CD software was working, so I disabled it. No luck there, either. After several days of searching, I found that the problem occurred only when I ran a particular multimedia program. Problems such as these can really make you want to pull your hair out.
Don't get the idea that configuration problems are always obvious. It's pretty easy to figure out when your sound board isn't working correctlyespecially with my previous problems. Even my neighbors knew I had a problem with my sound board. But what about the problem I was having with another application? It would work just fineat least just fine on most days. What would happen on the other days is almost indescribable. My machine would make a strange noise, the screen would look funny, and then one or more of my applications would simply disappear. (The same problem under Windows 95 caused the system to reboot; disappearing applications are better than a reboot and a testimony to Windows NT power to maintain control of the system.) I couldn't figure out what was going on. The solution to this problem turned out to be a Control Panel setup problem. One of my applications had overwritten the standard ODBC files. The new files were incompatible with this application in certain low-memory situations. I discovered that the problem always occurred when I had my word processor or any other large application open.
Tip: I could've had a lot less grief fixing the ODBC file problem if I'd recorded the time stamp for the files in that section or at least made note of the time stamp for my Windows NT files. You can do the same thing. Throughout this book, I've made every effort to tell you which files affect what functions. You can use this information when you're troubleshooting. It also comes in handy when you're recording information for a setup that works. When you get into a situation where the setup no longer works properly, one of the things you can do is go back to your notes to find a potential source of trouble.
As you can tell, I've had lots of fun digging up these real-life problems for you to learn about. The next few sections describe some of the types of problems you'll run into when your machine's configuration gets out of whack. I'll also provide you with some ideas on how to fix these problems.
Startup problems are the worst kind of configuration problems to fix because you can't use the tools Windows NT provides to find them very easily. What usually happens is that the settings for one or more devices conflict, get lost, or are somehow incompatible with the device you're using. When a device conflict affects the display adapter or your hard drive, you see a blue screen. (There are other, more insidious problems that give you a blue screen, such as a damaged registry or a virus, but the most common problem is that of failed or misconfigured hardware, so I plan to cover these issues in this section.) This blue screen means that Windows NT can't recover from this sort of problem.
So how do you get around this? The best way is to start the machine in fail-safe mode. (At the time of this writing, Microsoft was still using the VGA mode monikerI expect that they'll change this nomenclature to match Windows 95 before product release.) This mode starts your machine with the bare minimum of devices installed. That should get rid of the majority of your problems. The only two devices you really must have in order to start Windows NT are the display adapter and the hard drive. It's extremely unlikely that these two devices will have any conflicts. Even if a failed component still prevents Windows NT from starting, your list of likely suspects is greatly reduced. Windows also uses a generic VGA display driver. This will get rid of the rest of your problems. Even if your display driver is somehow corrupted or you've used the wrong settings, the generic VGA display driver will work.
The only way you know from the screen that you're in fail-safe mode is by the reduced screen resolution. Windows NT doesn't really tell you much in this regardsomething that Windows 95 actually does better because it displays the words Fail Safe in all four corners of the screen. You'll notice some other differences during the boot sequence. For one thing, Windows NT displays more messages as it loads drivers. It also tests your hard drives for errors and performs other diagnostics (the hard drive tests are the most noticeable).
You can get into fail-safe mode in two ways. The first is automatic. When Windows NT detects a problem in booting, it automatically sets up the machine to reboot in fail-safe mode. Of course, that depends on Windows NT actually detecting the problem. Sometimes it doesn't. If you make it most of the way through the boot process, for example, Windows NT might not detect a startup problem. The most difficult situation to detect is a sound board problem. The system is most or all of the way through the boot sequence before a sound board problem occurs. If Windows fails to detect the startup problem, use the manual startup method by selecting the proper option from the boot menu.
After your machine is booted in fail-safe mode, start looking for hardware or software conflicts. You might want to begin by removing all the applications and data files from your Startup folder. This is an especially bad problem area under Windows NT because its architecture almost ensures that some of your applications will have trouble running. Also, check WIN.INI to make sure that there are no LOAD= or RUN= lines in it. Go ahead and comment out any lines you do find so that the application won't run the next time you start Windows. After you make sure that all the conflicts are resolved, start your machine again.
Hardware-specific configuration problems can become an extremely complex issue under Windows NT. You can do a few things to make life a bit easier, though. The first thing you should do is look at the log in the Event Viewer. Normally, it displays a message for each device that wouldn't start. If you see two devices that didn't start, it's fairly certain that you have some kind of conflict, and not a failed device. Figure 24.1 shows an entry for a device error in the Event Viewer. It also shows the detailed description of the errornormally, this text tells you what went wrong with the device's initialization and gives you a starting place for troubleshooting. We covered the mechanics of using the Event Viewer in Chapter 3, " Performance Primer," so I won't cover them again here.
Figure 24.1. Hardware conflicts can become a thorny issue under Windows NTusing the Event Viewer can give you a place to look.
The event log normally records every kind of hardware failure that is the result of an actual failure or some kind of conflict. In some situations, however, Windows NT won't record a problem. What happens if you've installed a new device, for example, but it doesn't actually get started? Double-click the Devices applet in the Control Panel and you'll see a dialog box similar to the one shown in Figure 24.2. The first thing you should look for after you find the device in the list is a Started entry in the Status column. A blank tells you that the device wasn't started. This is where you figure out whether a device will start. Simply highlight the device you want to test and then click the Start button. If it doesn't start, look in the Event Viewer for a potential cause of the problem. On the other hand, if it does start, you might have to look at the device's starting mode. Just click the Startup button to display the dialog box shown in Figure 24.3.
Figure 24.2. A device could look like it's malfunctioning when you simply didn't start it.
Figure 24.3. Windows NT provides five starting modes for devices. You need to select the right one to ensure that the device actually starts.
You need to select one of the five starting modes described here:
Other types of conflicts occur under Windows NT. One of the biggest problems you could experience is if Windows NT provides a generic driver for a specific device and the vendor introduces a version of that device that conflicts with the driver. There's only one version of the Pro Audio Spectrum 16 Plus driver, for example, but there are four revisions of that board. The revision of the board you use can make a difference in how compatible the device driver really is.
Even more problematic is if you think you disabled a device feature but really didn't. Take another look at that Pro Audio Spectrum sound board. It includes a game port that really doesn't work all that well on high-speed machines. You might disable the game port and use those same settings for an adjustable game port. What happens, though, if the driver fails to do its job properly? I actually ran into this problem. The only solution was to reinstall the driver, but I was probably lucky in this case. Even if Windows thinks it has disabled a specific feature, you might want to view it as a potential area of conflict.
A Windows application configuration can go wrong in many ways. I recently installed an older 16-bit application that required Program Manager in order to install properly, for example. For whatever reason, the setup application didn't signal its need for Program Manager, and I thought the installation was a success.
Quite the contrary. The setup program had actually quit before it completed the installation, so I was missing an important INI file. The result was a piece of software that kept freezing my machine. I fixed the problem by reinstalling the software with Program Manager running. The moral of the story is to always install 16-bit Windows applications with Program Manager running. That way, you'll avoid any problems. Even if the application doesn't actually need Program Manager, you won't lose anything by running it.
There are other Windows application problems as well. Have you ever noticed how many applications want to modify your path statement in AUTOEXEC.BAT? Unfortunately, if the application actually does modify AUTOEXEC.BAT, the settings it needs won't appear under Windows NT. You have to set up the path in the System Environment Variables section of the System Properties dialog box (you access it by right-clicking My Computer and choosing Properties from the context menu). Of course, even intercepting these settings and making them in the program's stead can cause problems. If you let every application have its way, you'll probably have a mile-long path. Many applications run just fine without a path statement. However, there are two ways in which an application can fail.
I ran across the first problem area by accident. I added the file association required for a new application I installed. Whenever I double-clicked on a data file, though, I got a message that the application couldn't find the data file. The application started just fine, but it wouldn't load the data file. After a few hours of troubleshooting, I found that I could get rid of the problem by adding the application's location to my path.
Some applications fail in a big way if you don't add them to the path statement. CA-Visual Objects and some other large applications fall into this category. They usually provide some nebulous error message and quit before you can get them going. Either that, or the application loads and then refuses to load any add-ons because it can't find them. You might see symptoms of this problem when an application refuses to maintain the settings you save from session to session. Whenever you're in doubt, try adding the application to your path statement to see whether the problem goes away.
Shared-file (like DLL) corruption is another problem area. The DLL might not actually contain any bad data. It might work just fine with several other applications. One application might require an older version of the DLL, however, because it uses an undocumented feature of that DLL or uses some bug to its advantage. Sometimes you'll need to keep the old version of a DLL on disk to satisfy the needs of a particular application.
What happens if one application needs the new version of the DLL and another application requires the old version? It that case, you have to make a decision about which application to keep. In most cases, I use this situation as an excuse to upgrade my software. There usually isn't any reason to keep an old application around if it refuses to work with all your newer applications. In fact, an incompatibility of this type usually means that it really is time to retire that old application and get the newer version.
Tip: Many applications will look for the DLLs they need in their home directory before they look in the Windows system directory. If you have an application that needs an old DLL to run, try placing the DLL in the program's home directory. The problem with this approach is that Windows will only load one copy of a DLL. This means that you'll have to reboot the machine after using the old application to clear the old DLL from memory.
I ran into a really strange problem with one application on my machine. It was a communications program, but I imagine the same thing could happen with any application. Every time I tried to open this application, it filled the screen and then some. I had recently lowered my screen resolution in order to capture some screen shots, but I needed to run this application quickly to download a needed file from CompuServe. No matter what I did, as soon as the main application window appeared, the machine froze and I had to reboot. This is yet another example of an application that failed because its environment wasn't set up correctly. The point I'm trying to make is that the cause of failure isn't always obvious. You usually need to spend some time looking for the potential cause of a problem. Some of these causes can lead you down blind alleys into places you thought would never fail.
If you thought Windows software had a lot of failure points, you haven't worked with enough DOS software recently. There are some applications you'll never get to run under any version of Windows. Most of these applications fall into the game category, but I've seen others in this situation as well.
Tip: Windows NT is known for its inability to run most DOS applications welland quite a few, not at all. If you need the added security and reliability features of Windows NT, why risk those very features by using a DOS application? Unless you have a very good reason for doing so, now is the time to update all your DOS applications to their Windows equivalents. Better still, get 32-bit versions of all the programs to gain the added speed a 32-bit application gets under Windows NT.
An application that assumes it has the machine to itself, combined with users who keep asking for better performance, equals a situation in which the programmer is going to access the hardware directly in ways that the programming community as a whole would never recommend. This is precisely the situation some game and utility program vendors get into. Users are always demanding faster games with better graphics and sound, yet they want to run these programs on very outdated hardware. The game programmers usually have to resort to register-level programming to get the speed the user wants. Of course, this usually means that any mistake in programmingeven a small oneresults in a frozen machine or perhaps even a damaged hard drive. Fortunately, Windows NT isn't very susceptible to DOS application-induced failures. On the other hand, it gets around the problem by not running them at all.
Note: Running DOS applications is one area where Windows 95 far exceeds the capabilities of Windows NTeven if it can't run them all. Applications that fall into this category can be fixed in only one way: You have to run them in the Windows 95 MS-DOS mode or under native DOS.
So how can you fix that errant DOS application? I usually look at the application settings to see whether I can find a potential problem. Here's one scenario. You have a game program that always freezes when you run it in Windows, but it works fine from the DOS prompt. What's the problem? I found several setting-related problems that can wreak havoc with a game. One of them is that you can't assume that the sound board settings you use in DOS are the same ones Windows will use. Checking all your settings is an important part of getting a DOS application to run.
Other setting-related problems exist as well. Many of my games require that I add a SoundBlaster setting to my AUTOEXEC.BAT, for example. They read this setting and configure themselves appropriately. If you don't include the SET statement, the game freezes because it doesn't know what settings to use. As with every other environment setting under Windows NT, you'll find the SET statements in the System Environment Variable section of the System Properties dialog box.
Speaking of settings, most DOS applications are very sensitive to the environment settings. I find that compilers are the worst culprits in this area, but other applications can be quite challenging as well. It's usually a good idea to run every application that requires a complex environment setup from a batch file. Add all the required environment settings to the beginning of the batch file and make running the application the last step. You might have to change the program's environment size setting to make this work. See Chapter 2, "Exploring the Interface," for more details on the DOS application memory settings.
After you get past settings and strange hardware access problems, you might face a few other problems. One of the big problems, especially when talking about games, is a lack of conventional memory. We covered this issue fairly well in Chapter 2, but it pays to mention it again. Unlike Windows 95, you don't have any alternatives when a DOS application won't run in the conventional memory space that Windows NT provides. There are no memory manager solutions at your disposal, nor are there any TSRs you can unloadWindows NT as you see it is all there is. If a DOS application won't run on your system because it doesn't have enough conventional memory, you have to use native DOS or run it under Windows 95.
Windows NT provides a unique feature. You can define a recovery strategy when an application fails. Right-click My Computer and choose Properties. You should see the System Properties dialog box. Click the Recover button and you'll se the dialog box shown in Figure 24.4.
Figure 24.4. You can use the Recovery dialog box to define a recovery strategy for your system.
Figure 24.4 shows the default options I always select. You want Windows NT to write an entry in the event log. That way, you can see what happened later. All you need to do is restart the machine and use the Event Viewer. I almost always dump any debugging information to the MEMORY.DMP file as well. Giving this information to a vendor when you call to report the problem can make short work of finding the causeat least in some cases. Make sure that you automatically clear any old files as well by enabling the Overwrite Any Existing File checkbox. It won't help much if you give the vendor old information when you call.
Tip: There's always an exception to any rule. Most programmers will want to disable the Overwrite Any Existing File checkbox. I usually maintain a running MEMORY.DMP file when writing an application because it gives me a log of what's happening.
The Send an Administrative Alert checkbox comes in handy when you've got a new computer to test or the user is inexperienced. I always check this option if I think a new computer will give someone trouble, because some people are reluctant to report problems. Getting an alert allows me to check out the situation immediately. New users are generally reluctant to report problems because they don't want to make a bad impression on anyone. Selecting this option for every computer on your network is one way to get an excess of calls the user could easily handle for you.
I never enable the Automatically Reboot checkbox. The reason is simple: You can often see bits and piece of information on-screen after an application fails. If you instantly reboot, you won't get those added hints.
You can have quite a few memory-related problems under Windows NT. They fall into several categories. It's important to know which one you're dealing with before you attempt to fix it. The following list categorizes the various memory-related problems you could have when using Windows NT. Go through the list to see whether you can find the symptoms that match your particular problem:
There are probably other ways to corrupt memory as well. Windows NT uses other cache files, for example. Any these caches could become corrupted and cause problems for your system. You'll need to spend some time looking for the particular cache files on your system. Besides the ShellIconCache, I also had a ttfCache and a frmCache.dat file on my system. ttfCache affects the fonts listed in the Fonts folder. You might find that the fonts listed no longer match the fonts actually in the directory if certain types of memory corruption occur. The same holds true for the frmCache.dat file. Any type of cache corruption is easily cured by erasing the corrupted file and allowing Windows NT to rebuild it during the next boot cycle.
After you identify and clean up a memory-corruption problem, it's usually a good idea to find the application responsible. Most memory-corruption problems won't simply go away. You'll find that the corruption occurs over and over again at the worst possible moment. After you identify the culprit, you usually have to contact the vendor to find out whether a fix is available. If one isn't, you need to decide whether to live with the corruption problem or get a new applicationone that hopefully doesn't exhibit the same memory-corruption problem you're trying to get rid of.
So how do you find the culprit? You can't simply assume that the culprit is the foreground application; it could be a background application. For that matter, it doesn't have to be an application at all. A device driver could be causing the memory corruption as you use a specific device. A third class of problem is some type of interaction between two applications or an application and a device driver. You have to start somewhere, however, and looking at the applications you have running is a good place to start. You can follow this simple procedure to find many, but not all, of the memory-corruption problems on your system:
This kind of testing is time-consuming, but if you do it right, you can usually track down a stubborn problem in a matter of days. Unfortunately, memory problems are incredibly difficult to locate in an environment like Windows NT because so many things are happening at once. Each application and device driver interacts. You'll find that the hardest problems to find are those that result from three or four applications or device drivers working against each other. It always pays to take your time and do a thorough job of testing each potential problem area.
Of course, when you come to a conclusion, finding a permanent fix could prove to be the most difficult part the journey. You've probably gone through this beforethe waiting on the phone as each vendor points the finger at someone else. The reality of the situation is that there might not be an easy fix for some types of memory problems. You might just have to avoid the situations that cause them in the first place: get a newer version of the same application, or even go as far as to update your hardware.
Reboot your machine and select the VGA Mode option from the boot menu. It's important to actually see how your display looks in VGA mode because Windows NT doesn't really tell you much when it comes to booting in this mode.
Check out the Devices applet in the Control Panel. Make a list of the devices that are currently started and use it as a troubleshooting aid when you experience some kind of problem. Comparing the items on your list to those that are actually started during a crisis could help you pinpoint the source of the problem. You'll also want to note the startup mode for the device, just in case an application you install decides to change it.
If you have a DOS application that you can't currently run, try to find out why. You might find that the sound board or other device settings you're using don't match those used by Windows. If there's a conflict, try changing the DOS application settings to those used by Windows to see whether that will allow you to run the application normally. Also check for environment settings that could affect your capability to use the application from within Windows.
Devise a recovery strategy for your machine. If you're a network administrator, devise a strategy for all the machines on the network. Keep track of this strategy and change it as necessary to meet changing user and machine needs.